💡 Motivation and Context

Why: This came out of the cross-SDK compliance matrix in PostHog/sdk-specs — posthog-python is marked 🟡 Partial on the Capture contract because it has no runtime opt-out.

The capture spec requires an opt-out short-circuit:

Disabled/opt-out short-circuit. If the SDK has been disabled (disabled=true) or the user/process has opted out (opt_out=true), the call returns immediately with no event emitted. Opt-out state is usually persisted client-side and in-memory server-side.

The acceptance scenario Capture honors opt-out state (acceptance/public/capture.feature) is tagged @both, so it applies to server SDKs too.

The matrix note (compliance/posthog-python.md, n4 — Capture):

There is still no dynamic, runtime-toggleable opt-out API. The only short-circuit is the constructor-time disabled flag — a static kill-switch set once at construction, not the dynamic per-call opt_out_capturing()/is_opted_out() API pair other server SDKs (e.g. posthog-node) expose.

Backwards compatibility: Backward-compatible — adding opt_in()/opt_out()/is_opted_out() methods that toggle a new or existing internal flag is purely additive.

What changed

• New Client.opt_out_capturing(), Client.opt_in_capturing() and Client.is_opted_out(), plus the matching module-level helpers on the global client.
• The gate lives in Client._enqueue, which every event-producing API (capture, capture_ai, capture_exception, set, set_once, group_identify, alias) already funnels through — so one check covers them all, and events are dropped before anything is queued or sent.
• Feature flag evaluation and other non-capture APIs are deliberately unaffected, matching the *_capturing naming and the browser SDK's opt_in_capturing() / opt_out_capturing() surface.

Backwards compatibility

Purely additive. Three new methods, no signature or behavior change for any existing caller — a client that never calls opt_out_capturing() behaves exactly as before. The state is independent of the constructor-time disabled kill switch: opt_in_capturing() does not re-enable a client constructed with disabled=True (covered by a test).

Note the state is in-memory per client and does not survive a process restart, which is what the spec describes for server SDKs ("in-memory server-side"). Applications that need it to persist should store the user's choice themselves and re-apply it at startup; this is documented on the methods.

💚 How did you test it?

• New unit tests in posthog/test/test_client.py: events dropped with no network request while opted out (across capture/set/alias/group_identify), capture resumes after opt_in_capturing(), opt_in_capturing() does not revive a disabled=True client, and feature flags keep working while opted out.
• New module-level test in posthog/test/test_module.py covering the global-client helpers.
• Full CI-aligned checks run locally: ruff format --check ., ruff check ., mypy ... | mypy-baseline filter (clean), python -W error -c "import posthog", make public_api_check, and the full pytest suite — 4545 passed. The only 8 failures are pre-existing AI integration tests (posthog/test/ai/openai, anthropic, langchain) that need live provider credentials; they are untouched by this change.
• references/public_api_snapshot.txt regenerated via make public_api_snapshot (3 new functions, 3 new methods).

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• I updated the docs if needed.
• No breaking change or entry added to the changelog.

If releasing new changes

• Ran sampo add to generate a changeset file

🤖 Agent context

Autonomy: Fully autonomous

Produced by a scheduled agent run that reads the compliance matrices in PostHog/sdk-specs, ranks the open 🟡/❌ cells, and implements one backward-compatible gap per run. Tooling: Claude Code with shell, GitHub CLI and the repo's own make/uv checks.

Decisions along the way: several higher-ranked candidates were dropped after checking the actual repos — the .NET malformed-payload gap and the Ruby FeatureFlagEvaluations#enabled? default-value gap are already fixed on their main branches (the matrix notes are stale), and the posthog-js exception-metadata and posthog-go MCP exception gaps already have work in flight. Within this change, the gate was placed in _enqueue rather than in each public capture method so no path can be missed, and the scope was kept to capture only (flags untouched) to match the spec's wording and the *_capturing naming.

Follow-up work

• The matrix's other open Capture-adjacent items for this SDK are out of scope here and unchanged.
• The opt-in / is-opt-out specs are currently scoped client; if the server-side half of this behavior should be specified too, that is a change for sdk-specs, not this repo.

Created with PostHog Desktop

🤖 Generated with Claude Code